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(57) ABSTRACT 

A PC-based home automation system uses a low data-rate 
transport layer and COM-based software components for 
control of devices in a home automation network. The home 
automation system is merged with a messaging-based HAvi- 
network that uses IEEE 1394 as a high data-rate transport 
layer. The HAVi-network controls audio/video equipment in 
a home entertainment system. The home automation ser- 
vices and devices are registered as a HAVi-compliant ele- 
ments with the HAVi network's FAV or IAV device. The 
home automation resources (devices and services) have both 
COM OLE Automation Interfaces and HAVI-compliant 
interfaces to permit control of the home automation system 
from the HAVi-network. 
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METHOD AND APPARATUS FOR A LOW 
DATA-RATE NETWORK TO BE 
REPRESENTED ON AND CONTROLLABLE 
BY HIGH DATA-RATE HOME AUDIO/VIDEO 
INTEROPERABILITY (HAVI) NETWORK 5 

FIELD OF THE INVENTION 

The invention relates to a home automation system and to 
a home entertainment system. 

BACKGROUND ART 10 

A consortium of consumer electronics manufacturers, 
among which Royal Philips Electronics, has been working 
on specifications for a core of API's (application program- 
ming interfaces) for digital consumer electronics appliances 
in a home network so as to provide a standard for the 
audio/video electronics and the multimedia industries. An 
API specifies the method required for making requests to an 
operating system or application program. The home network 
is considered a distributed computing platform. The primary 2 o 
goal of the standard, referred to as the HAVi (Home Audio/ 
Video interoperability) architecture is to ensure that products 
of different vendors can interoperate, i.e., cooperate to 
perform application tasks. Current CE devices, such as home 
entertainment equipment (DVD players, DV camcorders, 2 5 
digital TV sets, etc.) are digital processing and digital 
storage systems. Connecting these devices in networks 
makes it possible to share processing and storage resources. 
This allows coordinating the control of several CE devices 
simultaneously, e.g., in order to simplify user-interaction. 30 
For example, a first device may instantiate recording on a 
second device while accessing an EPG (electronic program 
guide) on a third device. The home network provides the 
fabric for connecting the CE devices. It allows connected 
devices to exchange both control (one device sending a 35 
command to another) and AV (audio/video) data (one device 
sending an audio or video stream to another device). The 
network has to meet several requirements in order to achieve 
all this. It must support timely transfer of high-data- rate AV 
streams. The network must support self-configuration, self- 40 
management, and hot plug-and-play. It must require low- 
cost cabling and interfaces. 

The HAVi software architecture is platform -independent 
and based on Java. HAVi uses the IEEE 1394 high- 
performance serial bus protocol for transport of control and 45 
content among the devices connected to the network. The 
IEEE 1394 standard is a dynamically configurable, low-cost 
digital network. IEEE 1394 defines both a backplane physi- 
cal layer and a point-to-point cable-connected virtual bus 
implementations. The backplane version operates at 12.5, 25 50 
or 50 Mbits/sec. The cable version supports data rates of 
100, 200 and 400 Mbits/sec. The standard specifies the 
media, topology, and the protocol. The IEEE 1394 transport 
protocol is particularly useful for supporting audio and video 
communication protocols, due to its high data-rate capabil- 55 
ity. 

The HAVi architecture controls the CE devices in the 
network through abstract representations of the CE devices. 
The abstract representations are operated upon by a control- 
ler and hide the idiosyncrasies of the associated real CE 60 
devices. The abstract representation thus provides a uniform 
interface for higher levels of software. The abstract repre- 
sentations are registered with their control properties reflect- 
ing those of the device represented. The abstract represen- 
tations expose their Interoperability API's to the applications 65 
and collectively form a set of services for building portable, 
distributed applications on the home network. 
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The architecture allows a device to send a command or 
control information to another device in the home network. 
A HAVi-compliant device contains data (above abstract 
representation, referred to as Device Control Model or 
DCM, see further below) relating to its user-interface (e.g., 
GUI) and to its control capabilities. This data includes, for 
example, HAVi bytecode (Java) that can be uploaded and 
executed by other devices on the network. A HAVi- 
compliant device has, as a minimum, enough functionality 
to communicate with other devices in the system. During 
interaction, devices may exchange control and data in a 
peer-to-peer fashion. This ensures that at the communication 
level, none of the devices is required to act as the master or 
controller of the system. On the other hand, it allows a 
logical master or controller to impose a control structure on 
the basic peer-to-peer communication model. HAVi distin- 
guishes between controllers and controlled devices as 
explained further below. A controller is a device that acts as 
a host for a controlled device. A controller hosts the abstract 
representation for the controlled device. The control inter- 
face is exposed via the API of the abstract representation. 
This API is the access point for applications to control the 
device. 

HAVi-compliant CE devices are devices categorized as 
follows: Full-AV devices (FAV's), Intermediate -AV devices 
(IAV's) and Base-AV devices (BAV's). 

An FAV contains a complete set of the software compo- 
nents of the HAVi -software architecture (see below). An 
FAV is characterized in that it has a runtime environment for 
HAVi bytecode. This enables an FAV to upload bytecode 
from other devices for, e.g., providing enhanced capabilities 
for their control. An FAV may be formed by, e.g., a HAVi- 
compliant Set Top box, a HAVi-compliant Digital TV 
receiver, and an home PC. For example, an intelligent TV 
receiver can be the HAVi controller of other devices con- 
nected on the network. The receiver gets the bytecode 
uploaded from another device for creating a UI for this 
device and for providing external control of this device. An 
icon presenting this device can be made to appear on the TV 
screen and user interaction with the icon may cause elements 
of the control program to actuate the represented device in 
a pre -specified manner. 

An IAV does not provide a runtime environment for HAVi 
bytecode, but may provide native support for control of 
specific devices on the home network. An IAV comprises 
embedded software elements that provide an interface for 
controlling general functions of the specific devices. These 
software elements need not be HAVi bytecode and may be 
implemented as native applications on the IAV that use 
native interfaces to access other devices. 

A BAV may provide up loadable HAVi bytecode but does 
not host any of the software elements of the HAVi archi- 
tecture. A BAV is controllable through an FAV by means of 
the former's uploaded bytecode. A BAV is controllable 
through an IAV via the native code. Communication 
between an FAV or IAV, on the one hand, and a BAV on the 
other hand requires that the HAVi bytecode be translated to 
and from the command protocol used by the BAV 

The main software elements included in the core speci- 
fication of the HAVi architecture are the ones listed below. 
For a more detailed explanation of these elements, please see 
the HAVi spec, herein incorporated by reference. 

1) A 1394 Communications Media Manager (CMM) — 
acts as an interface between the other software ele- 
ments and the IEEE 1394. 

2) An Event Manager (EM) — informs the various soft- 
ware elements of events in the network such as the 
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changes in the network configuration that occur when on the network to locate another object on the network, 

appliances (devices) are added or removed from the Registering allows applications lo infer the basic set of 

network. command messages that can be sent to a specific device on 

3) A Registry — maintains information about the appli- me network. 

ances connected to the network and the functions they 5 As to communication: once an application has determined 

offer. Applications can obtain this information from the Ac capabilities of a device, the application needs to be able 

registry t0 access those capabilities. This requires a general commu- 

4) A Messaging System (MS)-serves as an API that mcation aUowm 8 a w|jcatbia to tesue requests to 
facilitates communication between the software ele- devices - ™" J? pK T . by the , ^ messaging 
ments of the various appliances on the network. Hie 10 f ^™ and D ™*- ™ 6 application sends HAVi messages 
messaging system provides the HAVi software ele- t0 DCMs the DCMs then engage in proprietary communi- 
ments with communication facilities. It is independent cation with the devices. 

of the network and the transport layers. A messaging . to *™ ™*W f te - in , order 10 su PP orl level \ 

system is embedded in any FAV and IAV. Hie messag- "nteroperatably a weU-defined set of messages is required 
ing system is in charge of allocating identifiers for the ]S be supported by all devices of a pamcuar known 

abstract representations at the FAV or IAV. TTiese c ass < e *. * e of ™ !^ vers > the c,a f , of Y CR s ' the 

identifiers are first used by the abstract representations clas f ofDV D &ym, e,c > ^ «™ uns . < hat a de ™ e can 

to register at the FAV or IAV. THen they are used by the work wlUl ex f m S 35 wel1 * Wlth ^ devices > 

abstract representations to identify each other within inrespective of the manufacturer. 

the home network. When a first abstract representation 20 , ™ es * th ' ee basic requirements support a certain minimal 

4 . j 4 . o „„ level of interoperability. Since any device can query the 

wants to send a message to another abstract represen- / 41 _ J . . t j • 

... . J . t . ^ , * capabilities of another via the registry, any device can 

tation it has to use the identifier of the latter while , f , / tL j • 

, • * adi determine the message set supported by another device, 

invoking the messaging API. _. r t . , & y tU 3 . 

_ A ^ . ^ f »T t i ^^«x . Smce applications have access to the messaging system, any 

5) A Device Control Module (DCM)-represents an ^ device can interact witn any other device, 
appliance on the network^ Application programs can Uvd x int erabilit ensures that devices can mX 
interact directly with a DCM This shields them from ^ at a basic leycl of However, a more 
the idiosyncrasies of each individual appliance, extended mechanism is needed to also allow a device to 

6) A DCM Manager— Installs the DCMs. It automatically communicate to other devices with any additional function- 
reacts to changes in the network by installing new 30 a lity that is not present in the embedded DCM' s on an FAV. 
DCMs for new appliances. p or example, embedded DCM's may not support all features 

7) A Data Driven Interaction (DDI) Controller— renders a 0 f existing products and are unlikely to support those totally 
GUI (Graphical User Interface) on a appliance's dis- new ones of future product categories. Level 2 interoper- 
play on behalf of a HAVi software element. It supports ability provides this mechanism. To achieve this, the HAVi 
a wide range of displays, varying from graphical to 35 Architecture allows uploadable DCM's as an alternative to 
text-only. the embedded DCM's mentioned above. The uploaded 

8) A Stream Manager (SMGR) — creates connections and DCM may replace an existing DCM on an FAV. An upload- 
routes real-time AV streams between two or more able DCM may be provided by any suitable source, but a 
appliances on the network. likely technique is to place the uploadable DCM in the HAVi 

The HAVi architecture specifies at least two levels of 40 SDD data of the BAV device, and upload from the BAV to 

interoperability, referred to as level 1 and level 2. the FAV device when the BAV is connected to the home 

Level 1 interoperability addresses the general need to network. Because the HAVi Architecture is vendor-neutral, 

allow existing devices to communicate at a basic level of it is necessary that the uploaded DCM will work on a variety 

functionality To achieve this, level 1 interoperability defines of FAV devices all with potentially different hardware archi- 

and uses a generic set of control messages (commands) that 45 lectures. To achieve this, uploaded DCMs are implemented 

enable one device to communicate with another device, and in HAVi (Java) bytecode. The HAVi bytecode runtime 

a set of event messages that it should reasonably expect from environment on FAV devices supports the instantiation and 

a device given its class (TV, VCR, DVD player, etc). To execution of uploaded DCMs. Once created and running 

support this approach a basic set of mechanisms is required: within a FAV device, the DCM communicates with the BAV 

device discovery; communication; and a HAVi message set. 50 devices in the same manner as described above. 

As to device discovery: each device in the home network The efficiency of level 2 interoperability becomes clear 
needs a well-defined method that allows it to advertise its when one considers resources needed to access a specific 
capabilities to others. The HAVi approach is to utilize device functionality. Level 2 allows a device to be controlled 
so-called SDD data: self describing data. The SDD data is via an uploaded DCM that presents all the capabilities 
required on all devices in the network. SDD data contains 55 offered by the device, whereas to achieve similar function- 
information about the device which can be accessed by other ality in level 1, this DCM would have to be embedded 
devices. The SDD data contains, as a minimum, enough somewhere in the network. For example, when a new device 
information to allow instantiation of a so-called embedded is added to a network, level 1 requires that at least one other 
device control module (embedded DCM). An embedded device comprises an embedded DCM compatible with the 
DCM is a piece of code pre-installed on a controlling IAV 60 new device. In comparison, level 2 only requires that one 
or FAV in platform-dependent code and using native inter- device provide a runtime environment for the uploaded 
faces to access the IAV's or FAV's resources. As mentioned DCM obtained from the new device, 
above, a DCM for a device is a software element that The concept of uploading and executing bytecode also 
provides an interface for control of general functions of the provides the possibility for device-specific applications 
device. Instantiation of an embedded DCM results in reg- 65 called Device Control Applications. Through these applica- 
istration of the device's capabilities with a registry. The tions a device manufacturer can provide the user a way to 
registry provides a directory service and enables any object control special features of a device without the need for 
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standardizing all the features in HAVi. The application is 
provided by a DCM in HAVi bytecode and can be uploaded 
and installed by each FAV device on the network. 

For further information, reference is made to the HAVi 
specification and the IEEE 1394 specification that are avail- 5 
able in the public domain. The HAVi core specification has 
been made available on the web at, for example, http:// 
www.sv.philips.com/news/press, and is incorporated herein 
by reference. 

10 

OBJECT OF THE INVENTION 

Currently, the HAVi spec does not consider the role of a 
PC in a HAM network. A PC may complement the HAVi- 
network in several ways. HAVi is currently concerned with 
audio/video only, and does not specifically address, e.g., 15 
control of a home security system, an air-conditioning unit, 
a lighting system. It is known to create a home automation 
system using dedicated software applications on a PC and a 
communication protocol, e.g., CEBus or X-10, for transmis- 
sion of commands via the power lines as the transport layer. 20 
These home automation functionalities do clearly not 
require a relatively expensive high-performance, high bit- 
rate transport protocol such as the 1394 Serial Bus. It would 
be some sort of overkill to integrate the modest home 
automation devices into a HAVi system and have them 25 
interconnected through the 1394 Serial Bus at the transport 
layer. 

It is an object of the invention to merge a low-bite rate 
home network with a high bit-rate home network. It is a 
further object to enable a HAVi-system and a low bit rate 
PC-based home automation system to co-exist and enhance 
each other's functionalities. 



SUMMARY OF THE INVENTION 



30 



35 



To this end, the invention provides a method for enabling 
a high data-rate first control network to control a device in 
a low data-rate second network. The high data-rate relates to, 
for example, IEEE 1394 whereas the low data rate relates to, 
for example power line enables CEBus or X-10. The first 40 
network comprises a HAVi network. The second network 
has a controller, e.g., a PC, for control of the device through 
an application interacting with a software object represen- 
tative of the device. The method comprises enabling the 
controller to be connected to the HAVi network using a 45 
HAVi-compliant transport layer. The method also comprises 
providing HAVi -compliant SDD representative of a func- 
tionality in the low data-rate network, and enabling regis- 
tering the HAVi SDD on the HAVi network. Preferably, the 
controller comprises a software service exposing a native 50 
interface to the application, and the method further com- 
prises enabling the software service to expose a HAVi- 
compliant interface to the first network, and enabling reg- 
istering the second network as an FAV device on the HAVi 
network. 55 

From the perspective of the system assembler, the control 
of the second network by the first network can be enabled by 
connecting the networks and loading the proper software 
components, e.g., through a diskette or through download- 
ing via the Internet. From the perspective of the user, the $q 
control is enabled by allowing the first network to commu- 
nicate with the second network. 

The PC controls the second network based on, for 
example, COM (Component Object Model), a technology of 
Microsoft. COM is an example of component-based soft- 65 
ware models for creating applications using modular soft- 
ware components. These technologies have become widely 



available and accepted in the software development indus- 
try. Other examples are DCOM, ActiveX, Java, JavaBeans. 
COM is a generic mechanism allowing applications to 
communicate in a consistent way and is a framework for 
developing and supporting program component objects. It 
provides capabilities similar to those defined in CORBA 
(Common Object Request Broker Architecture), the frame- 
work for the interoperation of distributed objects in a 
network. OLE (object linking and embedding) Automation 
provides services for the compound document that users see 
on their display, COM provides the underlying services of 
interface negotiation and event services (putting one object 
into service as the result of an event that has happened to 
another object). In this implementation home devices are 
modeled on the PC as OLE Automation objects (abstract 
representations) that use properties to expose device controls 
and events to signal state changes. OLE Automation is a 
COM technology that enables scripting and late binding of 
clients to servers. OLE Automation provides communication 
with other programs through calls to features (commands 
and queries) that the programs have made available for 
external use. Before using an object, a client application has 
first to obtain the object's interface pointer. The interface 
pointer is obtained through the network's directory by 
binding the object's name or by enumerating devices. Stan- 
dard COM API's for moniker binding can be used. Refer- 
ences to objects can be obtained by calling GetObject or 
CoGetObject with a string specifying the desired device's 
name or ID. The application can then manipulate the object 
by setting or retrieving its properties. When an application 
sets or modifies a property of an object corresponding with 
a home device the property-setting operation or modification 
operation is converted into a command that is sent across the 
network to the relevant device. The objects may differ in 
implementation and protocol support, but expose a similar 
property-based model to client applications running on a PC 
with a Windows operating system. 

In a typical embodiment of the invention, a PC-based 
home automation system uses a low data-rate transport layer 
and COM -based software components for control of devices 
in a home automation network. The home automation sys- 
tem is merged with a messaging-based HAVi-network that 
uses IEEE 1394 as a high data-rate transport layer. The 
HAVi-network controls audio/video equipment in a home 
entertainment system. The home automation services and 
devices are registered as a HAVi-compliant elements with 
the HAVi network's FAV or IAV device. The home automa- 
tion resources (devices and services) have both COM OLE 
Automation Interfaces and HAVI -compliant interfaces to 
permit control of the home automation system from the 
HAVi-network. 

For the sake of completeness, reference is made to, filed 
Aug. 13, 1998 of Lawrence Freeman for "Home Network 
Autoconfiguration", U.S. Ser. No. 09/133,622 of same 
Assignee and herein incorporated by reference. This docu- 
ment relates to automatically configuring PC's in a network 
in order to share resources registered with the individual 
PC's. Services and resources local to one PC are registered 
with the other PC and vice versa. The registry hides whether 
a service or resource is remote or local. In operational use of 
the network, a resource or service local to one PC is 
addressable from the remote PC as if it were local to the 
latter. A home network of PC's can be configured automati- 
cally in this manner. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The invention is explained by way of example and with 
reference to the accompanying drawings, wherein: 
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FIG. 1 is a block diagram of a system in the invention; and data-rate protocols. Note that 1394 is a relatively high-data 

FIG. 2 is a block diagram of a software element having rate protocol. PC 122 has a Windows-based operating sys- 

both a HAVi API and a COM OLE Automation Interface. tcra such as Win95 > Wui98 > WmCE, or Windows NT. The 

host software on PC 122 relies on existing COM technology 

PREFERRED EMBODIMENT 5 t0 provide means for application 130 to access devices and 

services in sub-system 104. Devices 124-128 are associated 

FIG. 1 is a block diagram of a system 100 in the invention. with abstract objects 132, 134 and 136 at PC 122. Objects 
System 100 comprises a first network 102 and a second 132-136 have properties that expose control functionalities 
network 104. Network 102 comprises a sub-system based on 0 f the associated devices. Abstract objects 132-136 supply 
messaging among software representations of the devices 1Q events to an application 130 to indicate state changes of the 
making up the sub-system. An example hereof is HAVi. objects brought about by the associated ones of devices 
discussed above. Network 104 comprises a sub-system 124-128, Application 130 manipulates objects 132-136 by 
based on modeling its devices as abstract objects. An object changing or setting their properties, e.g., as a result of 
has properties that expose control functionalities of the receiving an event. When application 130 modifies a prop- 
associated device to a software application. A state change 15 e rty of, e.g., object 132, the modifying operation is con- 
of an object as a consequence of an event from outside is verted into a command that is sent to device 124 associated 
passed on to the software application. The application therewith. In this example, PC 122 has the necessary acces- 
manipulates the objects by changing or setting their prop- SO ries and drivers for X-10, CEBus and consumer IR service 
erties. When the application modifies a property of an object provides to control a compatible lighting system, home 
associated with a certain physical device a command is sent 2Q security system and a TV. Before using an object, applica- 
to the associated device. An example of such a system is one tion 130 has first to obtain the object's interface pointer. The 
based on COM of Microsoft or on CORBA. interface pointer is obtained through a directory 138 by 

Network 102 in this example comprises a HAVi-based binding the object's name or by enumerating devices, 
sub -system that has an FAV 106, and first and second BAV's PC 122 is connected to FAV 106 at the transport layer via 
108 and 110 connected to FAVvia a 1394 bus at the transport 2 5 the 1394 serial bus. Devices 124, 126 and 128 are repre- 
layer. A BAV connected to FAV 106 may use a proprietary sented at FAV 106 by abstract representations 140, 142 and 
communication protocol between itself and FAV 106. BAV 144 as if they were BAV's. From the perspective of appli- 
108 has an abstract representation 112 that has been cation 130, controller 106 is an IAV or an FAV. Abstract 
uploaded to FAV 106. BAV 110 has an abstract representa- representations 140-144 are embedded DCM's or DCM's 
tion 114 that has been uploaded to FAV 106. FAV 106 further 30 uploaded via application 130 or other means, e.g., via the 
comprises a Registry 116, a Messaging System 118 and a Internet, and are provided with COM interfaces for corn- 
software application 120. Registry 116 provides an inven- municating with application 130 on PC 122 in order to 
tory of the devices, e.g., BAV 108 and 110, that have control objects 132-136 via application 130. Objects 
registered with FAV 106 and have thereby been functionally 132-136 control devices 124-128 using 25 proprietary 
connected to network 102. Registry 116 provides an API to 35 means and interfaces. A BAV application, e.g., "activate 
register software elements. Registry 116 maintains for each security system 128" or "turn on lights 124", can access the 
element registered its identifier and its attributes as specified PC-controlled services 132-136 as any other third party 
by the corresponding SDD. Registry 116 also provides a application 130. The BAV application can query a directory 
query interface that can be used by software elements to 138 of PC 120, determine what device are available, 
search for a target software element. Messaging System 118 40 describe them in SDD manner to HAVi network 102, trans- 
serves as an API that facilitates communication between the late and pass on messages from network 102 to 104, notify 
software elements of the various devices, e.g., BAV's 108 network 102 of events and state changes in network 104, etc. 
and 110, on the network. Messaging System 118 provides Accordingly, this implementation 30 serves as a cost- 
the HAVi software elements with communication facilities. efficient control bridge from HAVi network 102 to network 
Messaging System 118 is in charge of allocating identifiers 45 104. For example, the synergetic aspects of the combination 
for abstract representations 112 and 114 at FAV 106. These of network 102 and 104 become apparent in a home enter- 
identifiers are used by abstract representations 112 and 114 tainment system, where HAVi controls the audio/video pre- 
to identify each other within network 102. When abstract sentation and is synchronized with network 104 that auto- 
representation 112 wants to send a message to abstract matically controls the setting of ambient lighting, air- 
representation 114 it has to use the identifier of the latter 50 conditioning, curtains, etc. PC 122 can be given the 
while invoking the messaging API. Application 120 issues capability to upload HAVi-bytecode to FAV 106. 
requests to, and receives calls from, devices 108 and 110 a further interesting feature of this configuration is that 
through their abstract representations. For example, appli- pc 122 has the ability to be upgraded from BAV to IAV or 
cation 120 sends a message to abstract representation 112, FAV. This is a matter of installing the appropriate software 
whereupon abstract device 112 engages in communication 55 in PC 122. This enables exposing HAVi control services to 
with device 108. A typical feature of sub-system 102 is the devices in both network 102 and 104. Preferably, upon a 
capability of FAV 106 to accept uploaded bytecode as HAVi upgrade of PC 122, network 104 de-registers with 
abstract representations that get registered with FAV 106 and controller 106 and registers again as a new IAV or FAV after 
are interacted with in the runtime provided for control of AV the necessary components have been installed at PC 122. In 
devices 108-110. The HAVi architecture is dedicated to 60 case PC 122 presents itself as an IAV or FAV certain 
control of audio/video devices, e.g., a DTV and DVCR, that architectural requirements need to be met. For example, an 
typically require a high data-rate. IAV has to have as a minimum HAVi SDD data, a 1394 

Network 104 comprises a PC 122 connected to devices Communications Manager, a Messaging System, an Event 

124, 126 and 128 that use, for example, X-10, CEBus, USB Manager, a Registry, and a DCM Manager (see above under 

(not shown) service providers for communication with PC 65 "Background Art"). At PC 122, these software components 

122 via the power lines, and consumer IR and RF (not can be built using COM. These COM-built HAVi network 

shown) service providers, all of which are relatively low components are exposed as COM interfaces to non-HAVi 
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applications, and have HAVi-defined API's as prescribed by 
the HAVi spec to enable HAVi applications to access these 
components. This is illustrated in FIG. 2 that is a diagram of 
an implementation 200 of a registry using COM. Registry 
200 exposes a COM OLE Automation Interface 202 to s 
application 130 and a HAVi API 204 to application 120. In 
this manner, element 200 is a HAVI-compliant registry such 
as registry 116 at FAV 106, and also serves the purpose of 
playing the role of directory 138. Accordingly, COM or a 
similar technology can be used to build HAVi-compliant 10 
software elements at PC 122 by giving them HAVi API's for 
access from network 102 and COM OLE Automation Inter- 
faces for access by PC 122 as a Windows-based (e.g., 
Windows 95, Windows 98, WinCE or Windows NT) con- 
troller. This may not only apply to directory 138, but may 15 
also apply to elements 140, 142 and 144 that is the drawing 
have been presented as residing at FAV 106. The location of 
the DCM's code is not relevant as long as application 120 
has access to it via the HAVi architecture. 

I claim: 20 

1. A method for enabling a high data-rate first control 
network to control a device in a low data -rate second 
network, wherein the first network comprises a Home 
Audio/Video interoperability (HAVi) network, and wherein 
the second network has a controller for control of the device 25 
through an application interacting with a software object 
representative of the device, the method comprising: 

connecting the controller to the HAVI network using a 
HAVi-compliant transport layer; 

providing a HAVi-compliant Self Describing Device 30 
(SDD) representative of a controllable functionality of 
the device in the low data -rate network; and 

enabling registering the HAVi SDD on the HAVi network. 

2. The method of claim 1, comprising enabling registering 35 
the second network as a Base Audio/Video (BAV) device. 

3. The method of claim 1, wherein the controller com- 
prises a directory for exposing the software object to the 
application, the method comprising: 

enabling the directory to expose a HAVi-compliant inter- 4 q 
face to the first network for enabling the HAVi-network 
to query the directory; and 

enabling registering the second network as an Intermedi- 
ate Audio/Video (LAV) device on the HAVi network. 

4. The method of claim 3, wherein the directory exposes 45 
a Component Object Model (COM) Object Linking and 
Embedding (OLE) Automation Interface to the application. 

5. The method of claim 1, wherein the controller com- 
prises a software service exposing a native interface to the 
application, the method comprising: 50 

enabling the software service to expose a HAVi-compliant 

interface to the first network; and 
enabling registering the second network as a Full Audio/ 

Video (FAV) device on the HAVI network. 

6. The method of claim 5, wherein the native interface 55 
comprises an Object Linking and Embedding (OLE) Auto- 
mation Interface. 

7. The method of claim 1, wherein the controller com- 
prises a Personal Computer (PC). 

8. The method of claim 3, wherein the controller com- 60 
prises a Personal Computer (PC). 

9. The method of claim 4, wherein the controller com- 
prises a Personal Computer (PC), 



10. The method of claim 5, wherein the controller com- 
prises a Personal Computer (PC). 

11. The method of claim 6, wherein the controller com- 
prises a Personal Computer (PC). 

12. The method of claim 1, wherein the controller com- 
prises a Personal Computer (PC) with a Windows-based 
operating system. 

13. The method of claim 12, wherein the software object 
has an Object Linking and Embedding (OLE) Automation 
Interface to the application. 

14. A method of enabling a first network to interact with 
a second network, wherein: 

the first network comprises: 
a high data-rate transport layer; 
a first device having a first abstract representation for a 

first controllable functionality of the first device; 
a second device having a second abstract representation 

for a second controllable functionality of the second 

device; 

a first controller for control of the first and second 
devices through interaction with the first and second 
abstract representations that are registered with the 
controller with first and second identifiers, respec- 
tively; and 

a messaging system for allocating the first and second 
identifiers for enabling the first device to send a 
message to the second device by invoking a mes- 
saging system Application Programming Interface 
(API) while using the second identifier; 
the second network comprises: 
a low data-rate transport layer; 
a second controller with an operating system; and 
a sub-system controllable through a software applica- 
tion on the second controller; 
the method comprising: 
enabling registering a resource of the second controller as 
a third device with the first controller using a third 
abstract representation for a third controllable function- 
ality of the third device for enabling the first device to 
control the subsystem via the messaging system. 

15. The method of claim 14, wherein the first network 
comprises a Home Audio/Video interoperability (HAVi) 
network and wherein the second controller has a Windows- 
based operating system with a COM-based software service 
and a Component Object Model (COM) based Application 
Programming Interface (API) for enabling an application to 
control the sub-system. 

16. A controller device for control of a home automation 
network using a low data-rate transport protocol, the con- 
troller device comprising: 

a port for an IEEE 1394 high data-rate transport protocol; 

a Windows-based operating system; and 

a software component that comprises both an Object 
Linking and Embedding (OLE) Automation Interface 
and a Home Audio/Video interoperability (HAVi) com- 
pliant interface, 

wherein the controller device receives control signals 
via the HAVi-compliant interface and controls the 
home automation network via the OLE Automation 
Interface, in response to the control signals. 
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